The present invention relates to avoidance of software conflicts, and in particular, to method and system for avoidance of software conflicts.
The software conflict is one of serious problems in end users' experience of operating computers. In a software conflict, the application may report errors or become incapable of some useful functions. Even worse, some conflicts not only disable current applications, but also crash the computer, causing end users to reboot their computers. There are two major reasons for software conflicts:
(1) bugs; and
(2) dll/library/platform issue. For example, due to dll/library/platform upgrades or removal, there may arise between the calling program and the called dll/library/platform such a situation that the library does not have the called function, the number of called parameters do not match that of binary executable code of the program to fulfill the call, the types of called parameters do not match those of binary executable code of the program to fulfill the call, or the types of returned parameters do not match those of binary executable code of the program to fulfill the call, i.e. mismatch of the dependency between caller and callee. Thus the user cannot perform the required information storing or processing with the computer.
The bug of reason (1) can be solved by developers through strict tests. The library dependency of reason (2) is the major concern of the present invention. As is well known, the software consists of executable files and libraries (such as, dll in Windows or lib/so/a in Linux/Unix). The library is provided by the software or platform. When the executable file runs, it will load the library into its user space, and call the library according to an address or name space. A conflict occurs when the software loads an unmatched library, especial as the library has upgraded. At this time, the software tries to call a function in the library, but its parameters or the return values have been changed or even the function has been removed from the library due to update. Then the software will terminate since the library cannot provide the correct function.
In general, the prior art adopts three methods to solve the above problem. Method (1) is to check the library version when running. If the versions are unmatched, the executable will exit to avoid crashing computer (see for example, U.S. Pat. No. 6,397,378B1 “TEST EXECUTIVE SYSTEM AND METHOD INCLUDING DISTRIBUTED TYPE STORAGE AND CONFLICT RESOLUTION”). Method (2) is to reduce the library dependency. For example, the executable file is made to use only basic functions of the library, which will not change in a long term. This approach can solve the problem perfectly, but it requires developers to re-write the source code line by line, which needs more effort and leads to a higher cost. Method (3) involves the virtual machine technology. If the software is the sole one running on the operating system, it will never lead to conflicts. So many virtual machines can be built on the computer, and only one application runs on each virtual machine. This approach is not ideal, because 1) it will lower the computer performance significantly and 2) it will defeat the original purpose of library. On the virtual machine, the library looks like a “private” one for the application, which cannot be shared by others.